This logic is a bit suspicious to me. I think it would be helpful to expand on the comments here and/or rework the logic a bit.

Scenario 1: using the tool with no pipes -> output to stderr?
Scenario 2: using the tool and piping stdout somewhere -> output charm stuff to stderr?
Scenario 3: using the tool and piping stderr somewhere -> read from stdin, output charm stuff to stderr, and no charm rendering?

I would expect the logic to look more like:

if !isatty(stdout) { // stdout is being piped somewhere
  if isatty(stderr) { // stderr is still a tty, we can use that for TUI stuff
    // output = stderr
  } else { // no tty on either stdout/stderr, this would be the agent case
    // disable output, force stdin as input instead of tty input
  }
}

I'm not sure I fully understand, I think as the comment is saying I want the output to always be to stderr regardless of stdin piping status?

Okay, I think your original logic checks out to me after looking at it harder for a bit.

One thing I want to check: How does this logic interact with the CLI tool's ability to pipe data in to stdin? You should be able to test pretty easily by doing something like stl cmd 2>&1 | cat and also cat /dev/stdin | stl cmd 2>&1 | cat. I'm slightly concerned that if you simulate being an LLM using the second command, it would read in the bubbletea prompts from stdin, then make the API request and try to read in a JSON object from stdin at that point, which would and either hang without a prompt or error.

Sorry I need to merge this to support a customer before OOO, but very much intend to address this comment.

Sure, all I'd ask is that you test cat | stl cmd 2>&1 | cat (simulate being an LLM by forcing stdin/stdout/stderr to be non-TTY) for some stl command that both uses tea and makes an API request, just to confirm that it doesn't hang or error.

I gave this a quick test and had to also type {}<ctrl-D> and it seems to work

That's what I'm worried about. Will that work with an LLM, or will that cause the LLM to not know how to proceed? It might be best to close stdin after gathering all the necessary user input and before making a request. Or somehow otherwise let the CLI know to not read request data from stdin in this scenario.